Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Chapter 22
Optimal Backup and Recovery

Some of you work with mission-critical systems that must be available 24 hours a day, 7 days a week. With these types of systems, the time it takes to do hot and cold backups must be minimized. By minimizing the time it takes to do a hot backup, the performance effect on the system is minimized. By shortening the time it takes to do a cold backup, system downtime can be minimized.

Backup and Recovery Terminology

Following are definitions of some of the terms used in discussions of backup and recovery.

Hot backup Officially known as an online tablespace backup. This backup occurs while users are connected to the database and executing transactions (even to the table being backed up). Hot backups are performed on a tablespace basis.
Cold backup Officially known as an offline backup. This backup is done when the Oracle instance is not running. Cold backups can be performed on a tablespace basis.
Full backup A backup performed on every tablespace in the database. Typically, full backups are done as cold backups.
Export The Oracle export facility can be used as a method of performing backups but is usually not the preferred option because of performance issues.

An Oracle backup can consist of either a hot backup (done while users are connected and running transactions) or a cold backup (the database is shut down). Neither relies on Oracle to perform any functions except to keep the data files from changing during the backup. Using export can be an alternative to traditional methods because it includes the additional feature of allowing the structure of the database to change. However, an export does not provide for the flexibility and recoverability that traditional backups do. Rather than just copying the data as it exists, you can export and import the data to restructure the database and reduce fragmentation.

Although an export can be loosely considered a backup function, the export facility does not provide the same level of recovery as the standard Oracle backup facilities. However, there is more to export/import than just backup and recovery. Export/import can be useful in moving from one version of Oracle to another and for reconfiguration of the database. Export/import can also be used to move data between Oracle databases. Because exports do not allow for instance recovery and because many of the concepts of the export process are similar to those of the traditional backup procedure, this chapter does not address the export process as a backup method.

This chapter consists of a number of hints for how to minimize the effect of the backup and increase its performance. Some of the hints may be directly applicable to you; others may not apply to your configuration. By determining which hints might help you, you can find some useful optimizations for your configuration. The chapter starts by describing some of the characteristics of an Oracle backup and from those characteristics derives methods of improving backup and recovery performance.

RDBMS Operational Review

When you make any changes to the Oracle database, the changed information is not only eventually written to the database by the DBWR process, it is recorded in the redo logs by the LGWR process. When the log file is filled, a log switch occurs, which triggers a database checkpoint.

The checkpoint event ensures that all dirty buffers in the SGA are written out to the data files on a regular basis. The checkpoint can occur more frequently than a log switch for data integrity purposes.

When the log switch occurs, the previous log file is copied to an archive log file (assuming that you are running in ARCHIVELOG mode). This archive log file, along with the online redo log file and the last backup, allows for database recovery.

Backup Process

When you perform a backup of the data files, you not only copy the data itself, you copy valuable header information that identifies the data file. The header information tells Oracle when the data file was last backed up and the point in its operation at which it was when this backup occurred.

Oracle uses the information from the backup, the archive log files, and the online redo logs to recover the data to where it was when the system failure occurred. The backup feature is one of the things that makes Oracle such a powerful and robust RDBMS system.

As part of your ongoing backup process, it is important to keep all the archive log files safe and available in case a recovery is necessary. The archive log files allow you to restore your system to the point of failure should it become necessary to recover the system.

Recovery Process

If you are not running in ARCHIVELOG mode and a failure occurs, you can reload your database from the last full cold backup and start running from there. There is no facility in Oracle to recover any further if you are not running in ARCHIVELOG mode.

If you are running in ARCHIVELOG mode and a failure occurs on a data file, you only have to restore the damaged data file from a recent hot or cold backup. It is not necessary to restore the entire tablespace unless you are not running in ARCHIVELOG mode.

When you bring the tablespace back online, Oracle prompts you to apply various archive log files. Using these files, Oracle restores all the changes made to this data file until the time of the media failure. In this manner, no data is lost and minimal downtime is incurred.

If you have the Oracle Parallel Query option installed and have enabled parallel recovery, the time it takes to perform instance recovery can be greatly reduced. I find the Oracle backup and recovery process to be one of the things that separates Oracle from its competition.

The Oracle redo log architecture and the archiving processes allow Oracle to recover from almost any failure. These features provide a high level of data integrity and robustness.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.